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Introduction. 

This document in conjuncuoo with the SST network frame fonnat specification, defines the 
routing layer protocol used with the SST network. 



Functional Requirements. 

The bridging layer. 

- selects a root bridge node. 

- organize nodes in the network into an optimal spanning tree rooted at the root bridge. 

- routes terminai'to-terminal data traffic along branches of the spanning tree. Note that a host 
computer is treated as a terminal. A routing table is maiDtained in each bridge node for ail 
upsu^eam nodes. The path to downstream nodes is mherent in the strucmre of the spanning 
tree. 

- provides a service for storing packets for SLEEPING terminals. 

- propagates lost node informatioa throughout the spanning tree. 

- maintains die spanning tree links. 

- distributes network interface addresses. 

- organizes nodes into logical coverage areas on radio channels. 



Bridge Packet Definitions. 
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Bridge Control Byte Fields. 



Bridge header formal - This field is used to define die tormac of die bridge header. 

(M) s muiuhup. This is die norm;U bridge header format. The bridge heiuler includes 
>ource :uid de.NUnauon address fields. 



01 = poinc-co-poinc. The bridge header does NOT include source :Lnd destinauon 
address fields. 

Packet type • This field is used to specify die bridging layer packet type. 

Bridge parms - If diis bit field is set ON dien opuonal bridging layer parameters imznediately 
tbllow die bridge header. 

RSPRQ - This field can be used to request an cnd-to-end bridging layer response packet 
Nonnally diis field should be set ON for ATTACH, RARP and ARP request packets, «md 
should be set OFF for all other bridging layer packets. 

ATTI - A bridge node will set diis bit ON in an ATTACH.request packet whenever die 
source node is not in die bridge's routing table. The bit value in an ATTACRresponse packet 
follows die state of the bit in the associated ATTACH^equest packet received by the root 
node. If a terminal receives an ATTACH.response packet wiUi die ATTI bit set ON, it is a 
positive indication that die terminal was detached and has reattached to the network. 

Protocoi - This field is used to indicate the presence and type of higher layer data. 



000 = no higher layer data is contained in die packet 

001 = <m LLC message is contained in die packet 
010 s an NNMP message is contained in die packet 



Bridge Packet Types. 



DATArequest 

DATA.request packets are general purpose bridging layer packets used to send higher layer 
data and/or bridging layer parameters. 

A child node can periodically send a (possibly empty) DATA.request packet to its parent to 
ensure diat it is suU attached to die spanning u-ee. Note dial an ATTACH.request packet widi 
die ATTI bit set ON, is generated by a bridge node whenever die bridge node receives a 
downstream D ATA j^equest packet and die source of die DATA packet is not in die bridge's 
routing table. 



HELLO.request 
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A HELLO.rcqucst packet is used to solicit unscheduled HELLO.responsc packets from bridge 
nodes. A HELLO jequest packet can be broadcast by an unattached node when it wants to 
quickly reattach to the network. 

HELLO, response. 

HELLO.respon.se packets are sent periodicalJy at calculated time intervals by ail bridge nodes. 
In addition, bridge nodes will broadcast a HELLCresponse packet whenever a 
HELLO.request packet is received. HELLO.responsc packets arc used to build the spanning 
iree ;uid iire used to advertise pending message information and lost node information. 



ATTACH, request 

A node transmits an ATTACH.request packet, widi the RSPRQ bit set ON, to attach to the 
network. In addition, a node must transmit an ATTACRrequest packet at least once per 
ATTACH.TIMEOUT ume period Co maintain its path in the network. AU ATTACH.request 
packets are tmplicidy forwarded to die root bridge node. If die RSPRQ bit is set ON die root 
bridge node will return an ATTACRresponsc packet 

Higher layer data can be piggybacked onto ATTACH.requesi packets by setting the bridging 
layer destination address to die 16-bit address of die node for which die data is intended. If 
data is piggybacked onto an ATTACRrequest packet, die bridging layer will split the 
ATTACH packet into separate ATTACH and DATA request packets as soon as die next hop 
to die destinauon address is not on die path to die root node (i.e. the first upstream hop). The 
desdnauon address of die generated ATTACRrequest packet is die well-known address of die 
root node. 

If a bridge node receives a downstream DATA.request packet and die source node is not in the 
bridge's rouung table, then the bridge node will automatically generate an ATTACHjequest 
packet, widi die ATTI bit set ON* for the source node and forward it to die root node. The 
source address in die generated ATTACH.request packet is the same as the source address in 
die DATA packet (Note diat the DATA packet can simply be convened to an ATTACH 
packet) 



A TTACH, response. 

The root node will return an ATTACRresponse packet to die source node in the associated 
ATTACRrequest packet if die RSPRQ bit in die request packet is set ON. The ATTI bit will 
be set ON if die originating node was not fully connected to die network (i.e. if the node was 
not in die rouung table of a bridge node on the path of the request packet). 



Detach, request 

DETACRrequest packets are used to notify die network diat a node has detached. 
pETACH.request packets can be reliably broadcast diroughout die spanning tree by using die 
reliable tlooding mechanism described below. If a DETACRrequest packets includes a 
decedent list dien all nodes in die decedent list and die bridging layer source node are purged 
from die rouung table of nodes which receive die request 
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Address Resolution Packet (ARPy 

An i\ddress resolution packet is used lo acquire ihe l6-bii network ;uldress of a destination 
nude, when only die alias or 48-bii identifier or the node is known. 16-bit network addresses 
;u*e cached by the bridging layer. An ARP packet is generated automaticaiiy by die bndging 
layer whenever it receives a send request for which the desunation is not in its uiche. 

Reverse Address Resolution Paci<et (RARP), 

A RARP packet is used to set or change the a^ias and/or 48-bit long identifier of a device and 
to acquire a 16-bit network address. 



Constants, timers and data structures. 

ROOT.ADDRESS « hex 2000; 

HELLO.RETRY » 5; 
MAX.HELLO.LOST = 8; 
HELLO^SLOT^SIZE = .020 seconds. 
HELLO.MOD.V AL « 67. 
AVG^HELLO.SLOTS a 100. 
MIN.HELLO^SLOTS a HELLO^MOD.V AL. 
MAX^HELLO.SLOTS » (HELLO,MOD,VAL * 2) - 1. 

AVG^HELLO^PERIOD = HELLO.SLOT.SIZE * AVG.HELLO^SLOTS seconds; 
MIN.HELLO.PERIOD = HELLO^SLOT.SIZE * MIN^HELLO.SLOTS seconds; 
MAX^HELLoLpERIOD a HELLoLsLof.SIZE * MAX^HELLO^SLOTS seconds: 
HELLO^TIMEbirT= HELLO.RETRY * AVG.HELLO.PERIOD + I seconds; 
S^HELLO^W AIT « .5 seconds; 
MAX^HELLO.OFFSET « 200 milUseconds; 

BRG.RSP.TIMEOUTa 10 seconds; 

HOLD^DOWN^TIME « MAX.HELL0.PERI0D*(MAX.HELL0.L0ST+2) seconds; 

DEF^SAVE,CNTa3; 

MAX^SAVE^CNT=5; 

A W AKE.TIME^UNIT ^ . 1 seconds. 

AD DRESS^TIMEOUT a 30 minutes. 
MAX.ADDRESS.LIFE » 120 minutes. 

NETWORK.TIMEOUT a 12 aiinutcs. 

ROUTE^TIMEOUT = 1 0 minutes. 
ATTACH^TIMEOUT « 8 minutes. 

UT.OOR^TIME 3 20 seconds; (Unattached terminal out-of-rangc list entry timeout) 
UB.OOR_TIME = 100 seconds; (Unattached bridge oui-of-rangc list entry timeout) 
AT.OOR^TIME s 100 seconds: (Attached terminal out-of-rangc list entry timeout) 
AB_OOR.TIME a 300 seconds; (Attached bridge out-of-range list entry timeout) 
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UT,0OR«AGED.TIME = 300 seconds: < Atuiched terminal out-of-range list aged entry 

timeout) 

L'B^OOR^AGED.TTME = 500 seconds: (Atuiched bridge out-of-range list aged entry 

timeout) 

AT_00R.AGED.TIME = 500 seconds: ( Atuiched terminal out-of-range list aged entry 

timeout) 

AB_OOR.AGED,TTME s 1 000 seconds; (Atuiched bridge out-of-range list aged entry 

timeout) 

B,ENABLE.WAIT = 20 seconds; 
R^IDLE.TIME = 60 seconds; 
MAX,R.ARP,R£TRY = 10; 
MAX^ATTACH.RETRY « 5; 

B.TIMEOUT; (Bridging layer dmeout viUue - a function of the cost to the root) 

HOP.COST.ETHER = 20; 
HOP.COST.485LAN = 40; 
HOP.COST.SSRADIO = 125; 
HOP_COST.BUS-0: 

OOR,COST = 75; 

A heilo-dmer is used to measure a HELLO learning period. 

An inactivity-tinier is used to measure periods of network inactivity. 

A patli-tlmer is used to measure the maximum round-trip path delay for bridging layer 
packets which require a response. 

In any envied state, all nodes, except the root, maintain two lists: an in-range Ibt and an out- 
of-ranfte list 

.An entry in the in-range list contains die network address of a bridge node which was the 
source of a HELLO packet, th^ port used to communicate widi the bridge node, an aging 
factor^ and path cost information. Each entry in die in-range list is aged so Uiat it is discarded 
if no HELLO packet is received from the associated bridge within HELLO^TIMEOUT 
seconds. The aging factor for an entry in die in-range list is reset to zero whenever a HELLO 
packet is received. The aging factor for die entry of die parent node is reset to zero whenever 
any packet is received from the parent. In-range entries are classified as OLD after two 
HELLO periods pass without receiving a HELLO packet firom die bridge specified in die 
entry. 

An entry in die out-of-range list contains the network address of a bridge node, die port used 
to communicaiB with the bridge, and an aging factor. The out-of-range list is used to 
remember failed paths when a node is attempting to attach to die network. Entries in the list 
;u-e aged to indicate how long entries have been in die list. Out-of-range entries are classified 
iis OLD cifter two HELLO periods in die list Out-of-range entries are classified as AGED 
lUter OOR.TIME seconds in die list. AGED entries which are also in die in-range list are not 
selected as a potential parent node unless no odier in-range entries are available. AGED 
entries are discarded after OOR.AGED.TIME seconds have passed. 

Each node maintains a current.root variable, which is initialized to NULL. The variable 
contains die priority, root sequence, and ROOT ID die currendy active root node, where 
ROOT ID is a.48-bit device ID and/or alias. The variable is used to remember die current root 
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node. Attached nodes detach and go into an initial unattached state, without a network 
address, when the rooc node changes. 



[n general, an entry is added/updated in the in-range list of an enabled, attached or 
unattached node whenever a fflELLO packet, with the priority, sequence, and identifier 
of the current root node, is received, and the source bridj^e is not in the node's oui'oU 
ran^e list. 

Each node, except the root, maintains a current.parent variable, which contains the netwoHc 
address and padi cost infonnauon of the current parent of the node when the node is in ;ui 
atLiched suite. 

MSG.PENDING is (conceptually) a global state variable which is true when an incoming 
mess;ige is expected. 

State Transition Logic - notation and assumptions. 



Assumptions. 

The state transition logic in this document and the SST network assumes the following: 

- All nodes are assigned a LAN ID. 

- Packets which do not belong to the network specified by a node's LAN ID are discarded by 
the MAC layer and are not passed to. the bridging layer. 

- [n any enabled state, ail nodes score informauon derived from received HELLO^'esponse 
packets. 

- HELLO.response packets widi a cosi-to-root field value of 0 are firom the root node. 

* All nodes remain awake in any enabled unattached state. If SLEEPING nodes are unable to 
attach to the network after a TP^yimnm awake time has expired, an error is returned to a higher 
layer and reoies are bandied by the higher layer. 

- Root candidates must have a direct-link host port 

- All root candidates should be wired togedier. 

« A node loses its address and goes into an intermediate bold-down state whenever a new root 
node is detected. 



State Notation* 

State names used in this document are hierarchical. Suffixes are added to state tdenufiers to 
further refme a state defmition. An unqualified high-order prefix may be used to reference all 
possible substaies. 

The bridging entity in each node is in one of die following high-level node states. 

R -Root node. The node owns die root node address. 

RC - Root candidate node. The node does not have an address. 

BB - Bridge node widi a tool priority of zero. 

BR - Bridge node which has a non-zero root priority. 

B - Any Bridge node. 

T - Terminal node, 

* - any node. 
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II • subscript used to qualify a node state to indicate that the node docs not have a network 
address. For example. Tj^ is used to specify a termmaJ node that does not have a network 

address. 

All node suites are further qualitied by one of three attach states: 

D - The node is Disabled and unattached. 
U - The nude is enabled and Unattached. 
A • The node is enabled and Attached to the network. 

A node can be in an intermediate hold-down state: 

I - The node is in an Intermediate hold-down state. Bridge nodes, which were attached, 
transmit HELLO.response packets with an intinite cost in \he intermediate state. 

As an example, RC.U, is used to denote the node and attach state of a root candidate which is 
not attached to an SST network. 

The following substates are used to qualify an unattached node: 

idle - No network activity has been detected, 
wait - Wait for the fint HELLO.response packeL 
hello • A HELLO.response packet has been received, 
rarp - An address request is in progress, 
attach * An attach request is in progress. 

Root Resoiution ProtocoL 

Each SST network must have one or more root candidates. Each root candidate node enters a 
RC.U state when the bridging endty in the node is enabled. This state ends when 1) the root 
candidate determines that a higher priority root node already exists and enters the BR.U state, 
or 2) the root candidate assumes ownership of the root node status and enters the R. A state. A 
node in any BR state assumes the root node status if 1) the network becomes idle, or 2) a 
lower priority root node is detected. 

A root candidate which does not detect any activity assumes the root node status. If acuvity is 
detected, die root candidate remains in die RC.U.wait state until a HELLOxesponse packet is 
received or until network activity ceases. 

When as unattached non-candidate node receives its first HELLO.response packet it enters the 
*.U.hello state, and sets a hello-timer used to measure a HELLO teaming period. The hello* 
umer expires after HELLO.RETRY HELLO periods. 

In the R.A state die root node broadcasts a HELLOxesponse packet once per 
HELLO^PERIOD time period, according to a random distribution algoridim. Tbc root 
H£LLO.response packets contain a padi cost of 0, die priority of die root node, a root ID 
sequence number, and a ROOT ID which is either die unique long identifier or die unique 
alias of die root device. The pri rity, ROOT ED sequence, and ROOT ID fields are copied 
Into the H£LLO,response packets transmitted by all non-root bridges in the network. 
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A ROOT ID sequence number is stored in non-volatile storage by iUl root candidates. The 
sequence number is copied into RAM by the root node when it determines diat it is die rooi 
and die copy in non-volauie storage is incremented. The copy in RAlM is included in all 
HELLO.respunsc packets broadcast by all atuiched hndge nodes in die spanning vee. 



Hello packet priority. 

A "higher priority HELLO.response packet" is defined as any HELLO.response packet which 
conuuns a matching LAN ID and eidier 1) a higher concatenated USER PRIORITY+DEVICE 
PRIORITY field, or 2) an equal priority field and a higher priority ROOT ID. A ROOT ID 
can consist of a unique 48-bit device ID and/or a device alias. A "higher priority ROOT ID" 
is defined iis 1 ) die ID widi die higher 48-bit ID, or, 2) if neidier candidate has a 48-bii ID, die 
ID wtdi die alias widi highest siring value. Note dial if the ROOT ID docs not contain a 
unique 48-bii device ID, dien the 48-bit device ID is assumed to be ail O's. 

It may be possible for a root candidate to receive a HELLO.response packet widi an equal 
priority if die ROOT ID field in the HELLO.response packet matches die candidate's device 
idenufier. HELLO j^spoose packets widi a ROOT ID field diat matches die identifier of die 
local device and a non-zero path cost are assumed to be associated wiUi an out-of-date 
spanning tree and are discarded by die bridging layer. A matching ROOT ID and a zero padi 
cost causes a fatal error. 
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Root resolution state transition table. 



The suwe iransiticn table below defines trnnsitions in the root resolution process. 



^uiie 


event 


action 


next suite 


RC.D 


Bndeing enuty enabled. 


Enable MAC on ail network 
ports; bet HELLO^TIMEOUT 
inaciivitv-timer 


RCU.idle 


RCU.idle 


Inaciivitv-iimer expires. 




R.A 




Non-HELLO packet received. 


Set R^IDLE.TLME 
inaciivitv-umer. 


RC.U.wmi 




Higher priority HELLO 
packet received. 


Set R^IDLE.TIME 
inactivity-timer: set 
HELLO^TIMEOUT heUo- 
timer. 


BRa.U.hello 




Lower priority HELLO 
packet received. 




R.A 


RC.U.waii 


[nacuviiv-timer expires. 




R.A 




Non-HELLO packet received. 


SetRJDLE^TlME 
inactivity-timer. 


RC.U.wiiit 




Higher priority HELLO 
packet received. 


SetR.IDLE^TIME 
inactivicy-omen sec 
HELLO.TIMEOUT hello- 
timer. 


BRa.U.heUo 




Lower priority HELLO 
packet received. 




RJK 


BR.U 


Lower priority HELLO 
packet received 


SetR^IDLE.TIME 
inactivity-timer. 


BR.I dien 
RCU.wait 


R.A 


Higher priority HELLO 
packet received. 


Transmit HELLO packets 
with an infmite path cost for 
M AX_HELLO.LOST+ 1 
HELLO periods; set 
R.IDLE^TIME inactivity- 
timen sec 

HELLO.TIMEOUT hcUo- 
eimer. 


R.[ then 
BRa.U.heilo 
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Attaching to the Spanning Tree« 

Nodes ieam che best path to the root node by listening to KELLO. response packets from 
attached bridge nodes. Alter a learning time expires, a node without a network address sends 
a R.ARP. request packet to the attached bridge, in die in-nmge list, which provides the best 
padi to the root. A node widi a network address sends an ATTACH.request packet to die 
attiiched bndge in die in-rangc list which provides the best padi. The "best padi" ts primarily 
a t'uncuon of die padi cost to the root. 



Attach Selection Criteria. 

The criteria for selecting a parent bridge node iis die fint hop in a best path is defmed as 
follows: I) tlrst, only nodes which are in the in-range list, imd not in the out-of-range list, iire 
considered: 2) if no such node exists* dxen nodes which are in die in-range list but are 
classified as AGED, in the out-o^range list, are considered; 3) die node with the lowest cost to 
die root is chosen from the sec of "parent candidates"; 4) if two or more nodes have die same 
paUi cost, dien die node with the best signal strength is chosen (if a signal strength indicator is 
available): 5) if both die padi cost and signal strengdi are equal, dien the node with die highest 
attach priority is chosen; 6) if the path cost, signal strengdi and attach priority are equal, dien 
die node with die lowest network address is chosen. Elements 5 and 6 of die selection criteria 
are intended to group terminals into logical coverage areas under die control of a single bridge 
node, radier dian allowing terminals to randomly attach to any bridge node when physical 
coverage areas overlap. 

All parent candidates must be in die in die in-range list New entries in the out-of-range list 
are not considered as parent candidates. If no parent candidates exist an unattached node can 
wait and listen, or, optionally^ can solicit shoit HELLO.response packets by transmitting a 
global HELLCrequest packet 
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Bridge Attach State Transitions. 

The ^aue cransition table below defines tiie :>tate transitions required for a disabled bndge 
node to obtain a network address. Note thai a root candidate enters the B^.Lf.beilo state atter 
leiinung ot a higher prionty root. 



>avie 


event 


action 


next suite 


BB.D 


Bridging layer is enabled. 


Enable MAC on ail network 

ports; initialize in-ninge list to 
NULL; initialize out-of-range 
list to NULL. 


Bn.U.wait 


B^.U.wiiit 


HELLO packet received from 

the root 


Send RARP.request to die 
root; set B_TIMEOUT path- 
timer; set retry count to I. 


Bn-U.rarp 




HELLO packet received from 
a non-root bridge. 


Sec hello-timer. 


Bq.U.heilo 


B.^U-hello 


Hello-timer expires or 
HELLO packet received from 
the root node. 


Send RARP.requesc to the 
attached bridge widi the best 
path; set B.TIMEOUT path- 
timer, set retry count to I. 


B;,.U.rarp 


B:,.U.rarp 


RARP.response packet 
received. 


If address was received send 
ATT ACH.request to the 
uttsu^hsii with ihB h^t 

padi; set B^TIMEOUT timcn 
set retry count to 1. 


If address was 
received then goto 
B U Attach 
post error, goto 
BB.D or RC.D. 




path-timer expires. 


Resend RARP.requesc 
Increment retry count 


B^.U.rarp 




Retry count > 
MAX^RARP.RETRY. 


Initialize in-range list to 
NULL- 


B^.U.wait 




MAC lay^r retry error. 


Add respective bridge to out- 
of-rangelist Delete bridge 
from in-range list If list is 
not empty, send a 
RARP.requesc to the attached 
bridge with the best path; sec 
B.TIMEOUT timen sec recry 
counc to 1. 


If in-range list is 
empty then goto 
Ba.U.wait else 
goto B;,.U.rarp 
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The transition cable below defines the sDtc triuisitions required for an unaiiacfaed bridge node, 
with a network address, to attach to the network. Note thai an atuicbed bridge node enters the 
B. (J. wait sLite after detaching from the network. An unattached bridge node enters the 
B . U.aiuich state after receiving its network address. 



state 


event 


action 


nexi .sLite 


B.U.wiut 


HELLO packet received from 

Lhe root. 


Send ATTACH.request to the 
root: reset B^TLMEOLT 
timer: set retrv count to I. 


B.U.aiLich 




HELLO packet received from 
a non-root bridee. 


Reset hello-iimer. 


B.U.hello 


B.U.hello 


Hello-timer expires or 
HELLO packet received from 
\he root node. 


Send ATTACH.request to ihc 
attached bridge with the best 
path; reset B.TIMEOUT 
timer set retrv count to 1. 


B.U.attach 


B.U.aciach 


ATTACH.response packet 
received from bridge with 
best path in in-ranee list 




B.A 




ATTACHj^sponse packet 
received from bridge other 
than one with best path. 


(ignore) 


B.Uattach 




B.TIMEOUT timer expires. 


Resend ATTACH-request 
Increment retrv count 


B.U.attach 




Retry count > 
MAX^ATTACH.RETRY. 


Iniuaiize in-range list to 

NULL. 


B.U.wait 




MAC layer retry error. 


Delete bridge from in-range 
list If list is not empty, send 
an ATTACH request to die 
attached bridge with the best 
path; set B.TIMEOUT omen 
set retrv count to 1. 


If in-range list is 
empty daen goto 
B.U.wait else goto 
B.U.attacb 




HELLO packet received with 
shorter path cost and not in 
out-of*range list 


Send ATTACRrequesi to 
the attached bridge widi the 
best path; reset B.TIMEOUT 
umer set retry count to 1. 


B.U.attach 



Note that the ATTACH request packets* specified in die above transition tables, require an 
end-co-end response (i.e. an ATTACKresponse packet). 

State translUoa tables for an unattached bridge node which has a non*zero priority 
(BR.U) are identical to die above state tables for bridges with a priority of zero, widi die 
following exceptions: 1) An unattached bridge with a non-zero priority assumes the root node 
status whenever no packets are received within an R.IDLE^TIME inactivity period in any 
state; 2) an unattached bridge widi a non-zero priority enters die RC.U.wait state, after a BR.I 
hold-down period, whenever a lower-priority HELLO message is received. Note diat an 
inacdvity-umer is constantly ninning and must be reset whenever a pacltet is received. 

In :uiy attached or unattached state, a bridge loses its address, waits tor a hold-down period, 
and then goes to a *.U.wait state, whenever a new root node is detected. 
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Terminal Attach State Transitions. 



The >uue transition table below specifies the sLite transitions required for a disabletJ tenniniU 

nude 10 dLVxch to the network. 



>uite 


event 


action 


next siiite 


T.D 


Bndging layer is enabled. 


Enable MAC on ail network 
ports: mttialize in-range list to 
fWLL; initialize out-of-range 
list to NULL; set 
HELLO^TTMEOUT Dello- 
tiiner. 


Tj^.U.wait 


Tn.U.wiut 


HELLO packet received trom 
the root 


Send RARP.request tu the 
root: set B. TIMEOUT timer 
setretrv count to 1. 


T^.U.rarp 




HELLO packet received from 
a non*F0Ot bridee. 


Keset rlcJLi#U^ i iM^uu i 
beiio-timer. 


i;i.u. Hello 




Heilo-cimer expires* 


(sleep); reset 

HELLO.TIMEOUT heUo- 
timer. 


Tji.U.wait 


T^.U.hcUo 


Helio«umer expires or 
HELLO packet received from 
the root node. 


Send RARP.request to the 
attached bridge widi the best 
paUi; set B.TIMEOUT timer 
setretrv count to 1. 


Ta.U.rarp 


T^.U.rarp 


RARP.response packet 
received. 


If address was received send 
ATTACH.request to die 
attached bridge widi die best 

setretrv count to 1. 


If address was 
received dien goto 
T.U.attach else 

TD 




B.TIMEOUT timer expires. 


Resend RARP^uesL 
Increment retry count 


Ta.U.rarp 




Retry count > 

MAX RARP_RETRY. 


Initialize in-range list to 
^fULL. 


Ta-U.wait 




MAC retry error. 


Add respecdve bridge to out« 
of-range list. Delete bridge 
from tn-range list If list is 
not empty, send a 
RARP.request to die attached 
bridge with die best padi; set 
B.TIMEOUT umen set retry 
count to 1. 


If in-range list iN 1 
empty then goto \ 
Tj,.U.wait else ! 
goto T^.U.rarp 



In any attached or unattached state, a terminal loses its address, waits for a hold-down period, 
(uid dien goes to the T^^.U.wait state, whenever a new root node is detectetL 
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The cnnsition cable below defines che state cranbiuons required for iui unacLicbed termmaJ 
node, wtdi a oetworic address, to aiLich to the network. Note that ;ui attached terminal node 
enters the T.U.waii state after detaching trom the network. It' the terminal has a message 
pending, then the terminal will solicit shon HELLO.response packets with a alobid 
HELLO.requesi, and will wait HELLO.W AIT seconds for a HELLO packetf 



^tAte 


event 


action 


next state 


T.U.wiut 


HELLO packet received from 
the root 


Send ATTACH.request to die 
root: set B.TIMEOUT umen 
set retrv count to 1. 


T.U.atLich 




HELLO packet received from 
a non-root hhdee. 




T.u.nello 




Hello-timer expires. 


Pause (and sleep); send global 
ricL.i..v./. request, increment 
retry count ; Reset 
S.HELLO.WAIT hello- 
timer. 


T.U.wait 




neiiu-tiiner exptrcs* reiiy 
count > 


rVClUill UUWUuipiClCU |C(}UCS15 

widi error. 


ia.u.waii 


T.U.heUo 


Hello-timer expires or 
HELLO packet received from 
die root node. 


Send ATTACRrequest to die 
attached bridge with the best 
path; set B^TIMEOUT omen 
set retry count to 1. 


T.U.attach 


T.U.aitach 


ATTACRresponse packet 
receiveQ iroiii Dnagc witn 
best path in in-ranee list 


Set current j>arem to best 
paui onoge. 


T.A 




ATTACH response packet 
received from bridge other 
than one with best path (i.e. in 
response to an old request). 


(ignore) 


T.U.attach 




B^TIMEOUT timer expires. 


Resend ATTACH-requesu 
increment retry count 


T.U.atuich 




Retry coum > 
MAX.ATTACH,RETRY. 


Initialize in-range list to 
NULU send global 
HELLO.request: set retry 
count to 1; Set 
S.HELLO.W ATT hello- 
timer. 


T.U.wait 




enAK^ layer retry error. 


iviuvc unogc Lruui lu-ianijc 

list to out-of-range list. 

If in-range list is empty, send 
a global HELLO J-equest; set 
S.HELLO^WArrhcUo- 
umen set retry count to 0: 

else, if in-range list is not 
empty, send an 
ATTACH.request to die 
attached bridge with die best 
padi: set B.TIMEOUT path- 
cimen set retrv count to 1. 


in*rnni7P iivf w 
11 111*1 (UiSiC ii^v ir^ 

empty dien 
T.U.wait 

else T.U.aiuich 
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Belter poth found. 


Send ATTACRrequesi to. 
the attached bridge with the 
best path: set B.TIMEOUT 
path-umen set retry count to 
I. 


T.U.aiLicb 



In ;u)y attiiched or unattached ^itate, a temiinaJ loses its address, waits lor a hold-down period, 
;uid then goes to the T.^.(J.waii state, whenever a new root node is detected. 



Reliable Flooding Mechanism. 

Informauon can be Hooded throughout the network by using a reliable flooding mechanism". 
A node can flood a bridging layer request packet i) by setting the MAC layer and bridging 
layer destination addresses to ail Ts (i.e. a global address), 2) by setting the RSPRQ bit ON, 
and 3) by including a forward list in the packet. The forward list is identified by die bridging 
layer parameter type hexadecimal 08. It is used to specify which nodes must forward and 
acknowledge die request Initially, die forward list consists of ail bridge nodes which are 
eidier children or die parent of die node which generated the packet Modes in the forward list 
acknowledge die request packet widi a unicast response packet of die same packet type. Note 
diat only one flooded packet of a given type may be outstanding at a dme. If a receiving node 
in the forward list is attached to one or more branches of die spanning tree, odier dian die 
branch on which die request packet arrived, dien die node must rebroadcast die request packet 
The forward list in die rebroadcast packet will consist of each bridge node which is die first 
hop on such odier branches^ Note diat die forward list may be empty if die fust (and only) 
bop in ail other branches is a terminal node. 



Spanning Tree Linlc Maintenance and Recovery. 

A link in die spanning tree is loii whenever one of die following events occurs: 

1 ) A child node is unable to deliver a message to its parent bridge node. 

2) Achild node fmds a better path to die root node. 

3) MAX^HELLO.LOST consecutive HELLO response packets from a parent bridge node are 
lost by a child node. 

4) A HELLO response packet, from a parent bridge node or current root node, widi an infinite 
padi cost is received by a child node. 

5) A HELLO.responsc packet is received widi a new ROOT ID or Root Sequence Number. 

6) An attached node, which is not in a "DETACH HOLD.DOWN" state, receives a DETACH 
packet or HELLO.response packet widi its address in die packet's detached node list 

7) A parent node is unable to deliver a message to a child node. 
tS) A rouung table entry is aged and deleted. 

- Response acdons to events 1-6 are defmed in die detach state transition tables below. 

- Event 7 is discussed in die secdon which describes detach packet logic. 
• Event 8 is discussed in die section on routing table maintenance. 
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Detach State Transitions. 



Terminal Detach State Transitions. 



The triui.siiion uible beiow defines events which may cause a terminal to detach from the 
network. 



Nt;ue 


event 


action 


next ^Lite 


T A 




destination bridge from the 
in-range list; mitialize the 
out-of-range list to the MAC 
destination bridge; 

If the in.range list is empty» 
send global HELLO.request; 
set S.HELLO^WAIT hello- 
timer, set retry count to 1 ; 

else, if in*range list is not 
empty, send an 
ATTACH.request to die 
attached bridge wtdi die best 
path; set B.TIMEOUT padi- 
timen set retry count to 1 . 


rf in*rnna^ livr iv 

li Ul-|(UlslC iirHi l> 

empty then 
T.U.wiut 

else T.U.atuich 




Terminal address seen in a 
detached node list in a 
DETACH packet or HELLO 
packet and current time is 
pastHOLD^DOWN. 


Remove old entries from the 
in-range list: add die source of 
die DETACH or HELLO 
packet to the in-range list; 
inidalize the out-of-range list 
to NULL; send an 
ATTACH.request to die 
attached bridge with the best 
padi; set B.TIMEOUT padi- 
dmen set retry count to 1; set 
HOLD^DOWN to current 
time plus 

HOLD_DOWN TIME. 


T.U.aiiach 




Better path found to the root 
and no data transactions are 
pendinje. 


Issue a MAC.enquiry to die 
best path bridge. 


T.A 




Posidve response to a 

MAC_enquiry received from 
the best path bridge. 


Send an ATTACH request to 
the desdnation bridge. 


T.U.aitacb 




Negative response to a 

MAC.enquiry. 


Move the desdnation bridge 
from die in-range list to die 
out-of-mnee list 


T.A 
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MAX^HELLO^LOST 
consecutive HELLO packets 
from the parent node are 
missed, (Note that sleeping 
terminals must count skipped 
HELLO limes as misses.) 


Send an ATTACH-request to 
die atuiched bndge widi die 
best path: set B.TIMEOUT 
padi-timen set retry count to 

1, 


T.U.attach 




HELLO packet received from 
parent with an infinite path 
cost (siune ROOT ID). 


Remove parent and old 
entries from die in-range list; 
remove old entries from the 
out-of-range list: set 
HELLO.flMEOUT HELLO 
timer. 


T.U.wait 




HELLO packet received with 
new ROOT ID or Root 
Sequence Number. 


Update current-rooL 
Iniuaiize node identifier to ail 
Vs. Initialize in-range and 
out-of-ran^e lists to ^aJLL. 


Tj,.U.w»ut 



A sleeoing tcnninai should remain awake, whenever a tbreshold number «.e^or 2) 
foSie HELLO packecs have been missed from m parent node, unal a HELLO packet a 
«ceW«ii from .ts parent or until tbe terminal detaches and reattaches to a dtfferent parent 
node. 

A terminal which is waidng to receive a response time critical message can pertodicaUy 
SnS^S^Impty DATA.«quest packet to .ts pa«nt bridge node, to de^rmme a the parem rs 
stiU in range, if the message is not received in die expected amount of tm»e. 

A terminal which is in a DETACH HOLD.DOWN state must send an ATTACRrequest 
paS^tro^S node after the HOLD.DOWN state ends, to ensure thai u u fuUy attached to 
(he network. 



Bridge Detach State Transitions. 

The transition table below defines events which may cause a bridge node to det^h from the 
netwT ^detach- action, specified in the table, consists of broadcasang mfinue cost 
So pSets for MAX.HELLO.LOST*l HELLO periods, m an mtermeduue detach 
iB.I.detach) state before going to an unattached state. 
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sfjue 


event 


acuon 


next st:ite 


B.A 


MAC.send error. 


Detich. Remove die MAC 
destination and old entries 
from the in-range list; 
initialize the out-of-range list 
to the MAC destination 
bndge: set 

HELLO^TIMEOUT hello- 
timer. 


B.U.wait 




Bridge address seen in a 
detached node list in a 
DETACH packet or HELLO 
packet 


Detacb. Remove old entries 
from die in-range list; add the 
source of the DETACH or 
HELLO packet to the in- 
range list; initialize die out- 
of-range list to NULL; set 
HOLD_DOWN_TIME heilo- 
timer. 


B.U.wait 




Better patb found to the root 


Issue a MAC.enquiry to die 
best path brids^e. 


B.A 




Positive response to a 
MAC_enquiry received from 
the best padi bridge. 


Send an ATTACRrequest 
widi a decedent list to die 
destinauon bridi^e. 


B.Uattach 




Negative response to a 
MAC.enquiry. 


Move die destination bridge 
from the in-range list to die 
out-of-ranee list 


B.A 




MAX^HELLO^LOST 
coiisecutiye HELLO packets 
troqi the parent node are 
missed. 


Detach. Remove old entries 
liom die in-range list: 
initialize the out-of-range list 
to die parent node; set 
MAX_HELLO«PERIOD 
hello-timer. 


B.U.wait 




HELLO packet received from 
parent wttb an infinite patb 
cost 


Detacb. Remove parent and 
old entries from die in-range 
list; remove old entries from 
die out-of-range list; set 
HELLO.TIMEOUT HELLO 
timer. 


B.U.wait 

j 




HELLO packet received with 
new ROOT ID or Root 
Sequence Number and either 
bridge can not be a root 
candidate or packet has a 
hidier prioritv. 


Detach. Update cunent-root 
Initialize node identifier to all 
1 s. miuoiize iu*rangc onu 
out-of-range lists to NULL. 


B^.U.wait 1 


BR.A 


Lower priority HELLO 
packet received. 


Detach. Initialize in-range 
and out-of-range lists to 
NULL. 


R.A 



Note that a bridge node will never be in an attached HOLD^DOWN state. 
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Detach packet I gic 

A piirent nixJe generates a DETACH.request packet whenever it is unable to deliver a message 
to a child node. The two possible cases iire I ) the child is a bndge, or 2) the child is a 
tennimil. 

Case 1 - The lost node is a bridge. 

When a parent bridge node is unable to deliver a message to a child bridge node, it must send 
a OETACH.ret|ue$t p<icket, to the root node, which contains a detached node list that 
describes the lost subtree. The list contains all nodes in the routing table of the parent for 
which the lost bridge was the first upstream bop. All downstream bridge nodes in the padi of 
the DETACH.request packet must adjust their routing tables by deleting entries which match 
those in the detached list Detached node information is copied into a bridge's ''detached node 
list". 

Case 2 - The lost node is a terminal. 

Since terminals can be mobile diey can be lose often and must be notified quickly. When a 
parent node is unable to deliver a message to a terminal, it must generate a DETACKrequest 
packet, with the terminal specified in the associated detached node list, and flood the packet 
throughout the network using the reliable flooding mechanism described above. Any bridge 
node, which receives die DETACRrequest. adds the detached terminal to ics internal 
detached node list 

A bridge node in the forward, list does not forward an entry in die detached list of a 
DETACRrequest if the DETACH j'equest came from an upstream node, and die upstream 
node is not the first hop in die routing table entry associated with the entry in the detached list 
A DETACH.request is discarded if die detached list becomes empty. 

Upstream bridges, which only have terminals nodes (i.e. do not have bridge nodes) as 
children, must convert a received DETACH^equest to an unscheduled HELLO.response 
packet (widiout a forward list) and broadcast it immediately. Therefore, lost node information 
is tlooded diroughout die coverage area of die spanning tree. An awake unattached terminal 
should quickly discover diat it has been detached and can dien reattach. 

Each entry in a bridge node's detached list is advertised in HELLO response packets for 
MAX.HELLO. LOST^Z HELLO times or until die bridge determines die terminal has 
reattached. The same entry can not be in a bridge's detached list for a hold-down ume after it 
wiis deleted firom the UsL 

Since a node assumes diac it is detached if it does not receive a HELLO, response packet 
from its parent with MAX.HELLO.LOST HELLO time periods and detached node 
information is copied in HELLO response packet for MAX_HELL0_L0ST+2 HELLO time 
periods, a lost node is guaranteed that it will always discover when it becomes unattached 
widiin MAX.HELLO.LOST*HELLO.PERIOD seconds, in die worst case. 

Unscheduled HELLO.response messages are generated in each bridge node if a new detached 
bridge is discovered and die ume until die broadcast of die next scheduled HELLO.response 
packet is greater dian HELLO.TRICGER seconds. 
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Network Routing. 



A routing able is mainuined in eacb bridge node. The routing table has ;ui entry tor each 
known upstream node. (Downstream rouung is defined by the" structure of the bpannina tf« 



An exiunple routing ubie is shown below: 



deMinauon 


pi)r 
t 


first bop 


age 


child 
tlae 


delivery 
service 


aw<ake begin 
lime 


awake end 
time 


hexU^OA 


1 


hex 020A 


0 


false 


null 


null 


null 


hex()2UA 


I 


hex 020A 


0 


true 


null 


null 


nuU 


1 hex()80B 


1 


hex 080B 


i 


true' 


1 


15320 


15330 



In die example route table above, die bridge has diree descendants - 080A, 020A. and 080B, 
080A and 080B are terminal nodes and 020A is a bridge node, (Note ibat the node type can 
be determined by tbe address.) If die first bop field is die same as die desdnaiion field, dien 
die (opuonal) child flag field is set to true. The delivery service, awake begin ume, and 
awake end time fields only apply to cbild tenninal nodes widi a non-zero delivery service 
field. 

To forward an upstream bridging layer packet, a bridge node looks up die entry associated 
wid) tbe destinadon address in die bridge header. If die entry does not exist, die packet is 
discarded. If die entry docs exist, die MAC layer destinadon address is set to die first hop 
address in die route table.. The MAC source address is set to die address of die bridge node. 
(The bridge header addresses remain unchanged.) The packet is passed to die MAC entity on 
die port specified in die table. 

Route table entries are created or updated whenever a downstream unicast DATA, ATTACH, 
or ARP packet is received. If an entry does not exist for die bridging layer source address, an 
entry is created widi die desdnaiion field set to die bridging layer source address. The fields 
in die (old or new) entry for die destinadon are modified as follows: I) die first hop field set to 
die MAC layer source address, 2) die port field is set to idendfy die MAC endty which 
delivered die packet, 3) die age field is set to 0, and 4) if die desunadon and first bop fields 
!ire idenucai, die child flag field is set to true. 

The age field for each entry is incremented at regular intervals. An entry's age field is reset to 
0 whenever a packet is received from die desunadon associated wtdi die entry. If no packets 
are received from die desdnatioa of an entry for ROUTE.TIMEOUT seconds, die entry is 
deleted from tbe route table. 

Nodes can maintain dieir padh in die network by sending an ATTACH.request packet to die 
root node once every ATTACH.TIMEOUT seconds, where ATTACH.TIMEOUT must be 
sfaoaer dian ROUTE.TIMEOIIT. The ATTACH request packet can be piggybacked on a 
higher-layer data packet, if die node is acuve. 

If a DETACH.request packet is received from an upstream bridge node, dien each entry in the 
route table, with a destinadon field which matches an entry in the packet's detached list, is 
deleted. 

Ail nodes must maintaiaa current_pareot structure. The strucnire has a network address 
field, a port field, and an age field. The age field is incremented once per HELLO period. If 
die count stored in die age field reaches MAX.HELLO.LOST. die current_parent structure is 
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re-initialized to null values, and the node becomes detached. The age tleld is reset to 0 
whenever a scheduled or unscheduled HELLO.response packet is received from the node's 
porenL A downstream packets is forwarded by setting the MAC destination address to the 
curreni^parenLaddress and then passing the packet on the cuxrent^arencpon. 



All nodes must maintain a current^root structure. The structure has an age field* a 48-bit 
li)ng root ID tleld, a root alias tleld, and a rtxjt sequence tield. The structure is initialized to 
iiil O's (or null). The structure is checked, and possibly updated, each tune a HELLCresponse 
packet is received. If a node receives a HELLO.response packet which conuiins a long ID, 
;ilias, or root sequence number which is different than the associated value contained in the 
>tructure, then the node becomes unattached and loses its network address. The age tleld in 
the current^root structure is incremented periodically. If NETWORK^TIMEOUT minutes 
expire before a node receives a HELLCresponse packet from any bridge node, then the 
current.parent structure is re-initialized and de node loses its address. The age field is reset 
to 0 whenever a HELLO.response packet is received from any bridge node and the root node 
hiis not chimged. 



Address Resolution and Maintenance. 



Reverse Address Resolution Protocol (RARP) protocol. 

An address server in the root node maintains network addressing infonnatioQ in an address 
table, distributes network addresses to requesting nodes, and resolves network addressing 
problems. Each entry in the address table contains a device type field, a network address 
tleld, a long ID field, an alias tield, an in-use field, and an age tield. Entries in the table are 
aged so diat they can be reused after M AX^ADDRESS.LIFE minutes. Note that entries may 
remain in the table indefinitely. The age field in an entry is reset to 0 whenever a 
RARP.request or ATTACRrequest packet is received from the node associated with the entry. 

A separate sequential sec of unique node identifiers is mainfained for each device type. Each 
set begins with an identifier of 1 and ends with the mayimim range for the device type. 
Lower node identifiers are distributed before higher identifiets. 

A RARP.request packet can be used to: 1 ) acquire a network address from the address server, 
2) change an existing 48-bit long ID in the address table, or 3) change an existing alias in the 
address table. 

A node which does not yet have a unique 16-bit network address must request a 1 1 -bit node 
ID from die address server. The node uses a 16 bit multicast address until a unique node ID 
is assigned, Tlie low order IS bits of diie temporary address consist of the node's device type 
concatenated widi an 1 1-bit node ID of ail Ts. A RARPj'equest packet, containing the 
requesting node's unique 48-bit long ID and/or an alias, is sent to die address server by the 
requesting node. When a node requests a new address, the server first checks its address table 
to determine if the node already has a valid address. If the node doesn't already have an 
address, die server allocates die first available node identifier for die device type, to die node, 
if one is available. In either case, if an address is available, die server will set die network 
address field in die RARP packet to die allocated address and will set die return code bits to 
0. If an address is not available, or an entry already exists in die address table widi ambiguous 
identifiers, die address server will set die network address field to all I's and will indicate the 
error in die return code field. 
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The long identifier and/or alias in a RARP.requesi packet matches an entry in ihe address 
ubie i ) if maccliing 48-bit IDs and aliases are present m bodi, 2) if both concain a matching 
:\liivs iuid neither has a 48-bii ID » or 3) if both contain a matching 48-bit ID and neither has an 
;ilias. [f either the 48-bit ID or alias in the request packet is also in the address uible, luid the 
above cnteria are not met, an error is returned. 

Occ:Lsiotii\ily, a node may w.mt to chimge the association between a 48-bii ID and an alias. If 
the node simply requests a new address, iind its old address has not expired^ an error will be 
returTied. The requesting node can override the error and force a chimge by setting the New 
Aliiis or New Long ID bits in the RARP.request operation field. A change operation causes a 
new address table entry to be created if neidier the long ID or alias can be found in the address 
Lible. 

A requesung node can specify that it docs not have a 48-bit ID by not including it as a 
parameter or by including an ID of all O's. An alias is required if there is no 48-bi( ID. A 
requesting node can specify diat it does not have an alias by not including it as a parameter, or 
by including an alias with a length of 0. 

The address server will return a RARP.request packet to die requesting node as a 
RARP.response packet If the node, which generated the RARP.request packet does not 
receive a RARP.respoase packet within BRIDGE.TIMEOUT seconds, it must resend die 
RARP.request. 



RARP hexadecimal A-bit error codes. 

0 = good. 

1 = a node ID is not available. 

2 = Duplicate alias. The alias specified in die RARRrequest packet is already in die address 
table with a different long ID. 

3 - Duplicate long ID. The long ID specified in die RARPj'equest packet is already in die 
address table widi a different alias. 

4 = Invalid device type. 
F = Extended error code. 



RARP routing. 

Each bridge node maintains a RARP routing table which contains entries for upstream nodes 
which have recently sent a RARP request packet to the root node. 



An example RARP route table is shown beiow: 



1 lone ID 


alias 


port 


tirst hop 


network address 


return code 


ace 1 


hex 1003508A990C 


null 


1 


hex 020A 


hex FFFF 


invalid 


0 


hex 10O3508A920B 


term2 


1 


hex FFFF 


hex 080C 


0 


3 



Whenever a RARP^equest packet is received, an entry is created (or updated) in die RARP 
route table and die long ID and/or alias fields in the entry are set to die values specified in die 
request packet The node which Initiated the request is deflned by the i ng ID and/or 
alias. The long identifier and/or alias in a RARPxequest packet matches an entry in die RARP 
route table 1) if matching 48-btt IDs and aliases are present in bodi, 2) if bodi contain a 
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matching alias and ncitier has a 48.bit ID . or 3) if both contain a matching 48-bit ID and 
neither has an alias. The return code is initialized to invalid to indicate that an associated 
RARP.response packet, destined for the node which originated the RARP.request has not 
been received. The pon field points to the port on which the RARP.request was received. 
The network address is set to the bridgmg layer source iiddresis of the RARP.requesi packet, 
( Nonniiily. the node ID in the bridging layer source address wiU be iill I's, which is the detauit 
global node ID used before a unique network node ID is obtained. If a node is attempting to 
chiuige Its long ID or ;ilias, then the network address may be unique.) The tirst hop tieid wiil 
be set to die MAC source address. The age field will be set to 0. 

Normally, a bridge node will forward RARP.request packets to the root node on the port 
specified in die current^parent structure. However, if a bridge node receives a RARP.request 
packet, and 1) an entry for the node which inidated the request is already in die RARP route 
uible, 2) die entry has a return code field which'is valid, and 3) die network address fieid is not 
;dl I's, dien the bridge can simply return a RARP.response packet to die source node. The 
return code and age fields in die route table entry are not modified. The network address and 
return code fields in die RARP.response packets are set to die values contained in the RARP 
route table. 

When a bridge node receives a RARP.response packet from die root node, it will update die 
return code and network address fields in die RARP route table entry for die node which 
inidated die request RARP.response packets are forwarded on die port specified in die route 
table entry. The MAC destination address is set to the first hop address. 

RARP route table entries are aged (quickly) so diat older entries are discarded in 
RARP.TIMEOUT seconds. 

Address Resolution Protocol (ARP) protocol. 

A node can request the 16-bii networit address of anodier node by sending an ARP.request 
packet to an address server in die root node. The ARPj'equest packet must contain either die 
48-bit identifier or die alias of die target node, but not both. The address server returns die 16- 
bit network address of the target node in an ARP.response packet if the target node exists in 
die server's address table. An address of all Ts and an error is remraed if die target node is not 
in die address table. 



ARP 4'bit hexadedmd error codes. 

0 = good. 

1 = long ID noc found. 

2 = alias not found. 

F s extended eiror code. 
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Address Maintenance. 

A node wiil lose its address if: 

1 ) The root node changes (i.e. either a different ROOT ID or ROOT ID Sequence Number is 
detected m a HELLO.response packet). 

2) It has not received iui ATTACH. response packet, from the root node, within an 
AD DRESS ^TIMEOUT time period. 

3) No network activity is delected within a ^fETWORK_TIMEOL^T time period. 

The root node can change because 1 ) the root node is lost or 2) a new root is chosen with the 
root selection protocol. All bridge nodes which detect the change must broadcast 
HELLO.response packets at scheduled times with the new ROOT ID and an infmite path cost 
for MAX.HELLO.LOST+2 HELLO times. If die root node is lost the new ROOT ID will be 
either a 48-bit long idendfier of all O's, if the old ROOT ID was a long identifier, or a null 
alias if the old ROOT ID was an alias. If die a new root is chosen die new ROOT ID will be 
eidier the 48-bit long identifier or alias of die new root node. Note diat a new occurrence of 
die same root node can be always be detected because die ROOT ID sequence number will 
change. 

A node can maintain its address by sending an ATTACH.request packet to the root node at 
least once per ADDRESS.TIMEOUT ume period. Note diat a node must send an 
ATTACH-request to die root at least oiice per ROUTE.TIMEOUT time period, to maintain its 
padi to die root in diet spanniiig tree; dierefore no special logic is required for address 
maintenance. If die node is active it can simply piggyback die ATTACRrequest on a higher- 
layer downstream data packet. The root node will return an ATTACHj'esponse packet, and 
die node can reset its ADDRESS.TIMEOUT umer when die response packet is received. 



HELLO Timing. 

HELLO.response packets can be unscheduled or scheduled. 



Unscheduled HELLO tlndng. 

Unscheduled HELLO response packets are broadcast in response to HELLO.request packets. 

In addition, an unscheduled HELLOxesponse packet is generated in each bridge node if a new 
detached bridge is discovered and die time until die broadcast of die next scheduled 
HELLO.response packet is greater dian HELLO.TRIGGER seconds. 
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Scheduled HELLO timing. 

Each atuiched bridge node broadcasts one scheduled HELLO.response pjicket per 
HELLO^PERIOD seconds. Each HELLO.PERIOD time period is divided into 
AVG.HELLO^SLOTS slots, where each slot is HELLOES LOT.SIZE seconds. Initkilly. a 
bridge node chooses a slot iuid broadcasts a HELLO.response packet. The HELLO.response 
packet contains a seed * tleld which is used in a weil-known "hello randomization algorithm * 
to determine the next hello slot and the next seed for the bridge node's next HELLO .response 
packet. The algorithm guarantees that a bridge node will randomly broadcast its next 
HELLO.response packet within a MIN.HELLO.PERIOD second to MAX.HELLO.PERIOD 
second time window after its last HELLO transmission. 

Since significant cumulative delays in hello uming are prohibited, nodes can execute die 
hello randomization algorithm i dmes to determine die dme (and seed) of the i-tli successive 
scheduled HELLO j^sponse packet from a bridge node. For example, a SLEEPING terminal 
node can initially synchronize on a HELLO.response packet from its parent The terminal can 
calculate the time of a future HELLO j-esponse packet from its parent and can power-down 
widi an acuve timer intenrupt set to wake it just before die broadcast of die HELLO^response 
packet is expected. 

Contention delays incurred during die transmission of a HELLO.response packet are recorded 
in a "displacement" Geld in die packet. The displacement field specifies die transmission 
offset time, in hundreddis of seconds, from die calculated transmission time. Note that errors, 
caused by rounding to die nearest displacement, can cause some drift in calculated 
transmission times. Therefore, nodes should resynchronize every time a HELLO.response 
packet is broadcast If die displacement field, in a HELLOjesponse packet is set to ail Ts, 
dien die transmission time of the packet does not coincide with a calculated hello dme, and 
die packet should not be used for hello synchronization. The displacement is set to all I's in 
unscheduled HELLO.response packets and is set to all Ts in scheduled HELLO.response 
packets whenever the packet can not be sent within MAX.HELLO.OFFSET milliseconds. 

If on expected HELLO j-esponse packet is not received at die calculated time, dien die 
receiving node should wait for the mflginniin displacement time before assuming the HELLO 
packet was missed. The maximum displacement dme can be calculated, in milliseconds, by 
multiplying die number of hello periods, since die last HELLO packet was received, by 
MAX.HELLO.OFFSET. 

Note diat HELLO slot boundaries for different bridge nodes are not necessarily aligned (i.e. 
as in slotted ALOHA). In fact to increase randomizauon, bridge nodes should avoid slot 
cdignment A "HELLO slot" is simply die unit of time used in the randomizadon algorithm. 

Default HELLO.PERIOD and HELLO_SLOT_SIZE values are set at compile dme and are 
well-known by all nodes. Modified HELLO.PERIOD and HELI .0,SLOT,SIZE values can 
be set by die root node and advertised dirougtaout die network in HELLO.response packets. 
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The algorithm used for HELLO time calculation is defined by the "C routines below. The 
routines assume thai lastjiellojime and tastjiello^seed variables are maintained for each 
bndge node of interest A bridge node should set the lastjiellojime variable, associated with 
its HELLO.response packet broadcasts, to die last HELLO transmission time, adjusted to 
account for any displacement. For example, ii* a bridge node's HELLO transmission ume is 
delayed approximately 20 milliseconds, then it should set the displacement field in die packet 
CO 2 ;uid seLs its lastjiellojime variiible to the transmission time minus 20 milliseconds. 

Two rouunes are shown below: 

seC.last.heilo - is used to extract lastjiellojime nnd lastjiellojeed from a received 
HELLO, response packet The last_hello_dme variable is adjusted to account for the 
displacement field. The routine assumes diat packets are accurately ume*stamped (i.e. by the 
MAC layer) when diey arc received. 

calc.next.hello - is used to calculate die time and seed of die next HELLO.response packet 
for die bridge specified by die address passed to die roudne. 

The rouunes rely on die address table functions - Insert and Lookup. Insert enters an address 
into a table, if it does not exist and reums the index. Lookup returns the index of an address, 
if it exists. 

int sct_Iast_heUo.ume(PACKET * heilo jacket) 

{ 

offsetsfaeUo4)acket->heiIo.secd & B^MASK.DISP; 
if (offset=B^MASK.DISP) 
return - 1 ; 1^ next hello time cannot be calculated, if die displacement is all I's */ 

/* else, determine die seed and hello ume */ 
i=Insert(hello_packet->mac_s_addr); 

liist.hello_ume(i]shello j)ackei->receive_dme - ((TIMEKoffseD); 
Iast_hello_seed(i]=hellojiackei->hello.sced » 2; 
return 0; 

} 

int calc.next_hello(int address, TIME* ncxi.timc, int* next.seed) 

{ 

int next.siot; 
isLookup(addfess); 

if (t<0)refuni«l; /* next hello dme cannot be calculated*/ 

*next.dmealas|_heUo.time(i1; 
♦next_seed»lasLhello_sccd[i]; 
while (*next_umc <= currcnt_time()) 

{ 

next^slot=((*next.seed+addrcss) % HELLO^MOD^VAL) -h HELLO.MOD.VAL; 
♦next.ume ncxt.sloi * HELLO.SLOT^SIZE; 
♦next^seedfl8((seed + 3) 0x2A) & Ox3F; 

} 

return 0; 
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Sleeping terminal support 

The bridging layer provides a service which will .store pending messages tor SLEEPING 
lenninids. TemiinaJs request the service by setting the optioniU "delivery service" p<if:uneter 
(type bexadectmal OE), in the optional parameter <irea in luiy bridging layer packet. If a child 
node does not set the parameter or sets it to 0 (the default value), then the parent bridge node 
will attempt to deliver packets to the child node immediately. The child node is assumed to 
he lost whenever a packet can not be delivered. If the parameter is set to U the source child 
node is assumed to be a SLEEPING terminal and the parent node will not attempt to deliver 
packets to the child node until the child notifies the parent that it is awake. If die parameter is 
set to 2, the parent bridge will attempt to deliver packets immediately, widi a reduced retry 
count: if a packet can not be delivered, the parent will store the packet until the child node 
notifies die parent that it is awake (or a save time expires). 

A child node can notify its parent node that it will be awake by setting an optional "awake 
dme" parameter (type hexadecimal OC) in any bridging layer packet The awake time is 
specified in AWAKE.TIME.UNIT time units. A value of all I's indicates forever. By 
default the awake time period is assumed to follow die end of transmission of the packet 
containing die awake time parameter. Optionally, an offset can be specified with die optional 
"awake lime offset" parameter (type hexadecimal OD). The awake dme offset parameter 
specifies an offset time at which time the terminal will wake up and stay awake for the time 
specified in die associated awake parameter. The offset is specified in AW AKE.TIME.UNIT 
time units and is added to the end^of-transmission time. Tliis opdon allows a terminal to 
initiate a transaction, sleep for a statistically calculated time period* and then wake up to 
accept a response. 

If a bridge node determines diat a SLEEPING terminal is sleeping dien it will store packets 
destined for die tenninal for a number of HELLO periods, or until delivery to die child node is 
attempted. The number of HELLO periods diat a packet will be saved is set to 
DEF.S AVE^CNT, by default and can be set from 0 to MAX.SAVE^CNT by a child node 
with die opuonai "store message count" parameter (type hexadecimal OF). Whenever a bridge 
node is storing a message for a terminal, the terminal's address will be included in the 
"pending message list" in successive HELLOxesponse packets broadcast by die bridge node. 
If die message can not be delivered within "store message count" HELLO periods dien die 
bridge node will assume that the child terminal node is lost 

As an example, a SLEEPING terminal might nodfy its parent diat it will be awake, in a ume 
window when a reply message (Le. from a host computer) is expected, by setting die awake 
dme and awake dme offset parameters in die packet which solicited die reply. If die reply 
message is not received when expected, die terminal can alternate between sleep periods and 
short awake dme periods. An empty DATA.request packet containing a "wake ume" 
parameter can be used to notify the parent of successive wake dme periods. (Note that a 
parent node will generate an ATTACRrequest packet widi die ATTI bit set ON whenever a 
DATA.rcquest packet is received from a terminal and a roudng table entry does not exist for 
die terminal. Therefore, die empty DATA.request also ensures that the node is still attached 
to die network.) Whenever a SLEEPING terminal expects a reply message die terminal 
should wake up to receive all HELLO.response packets from its parent If an expected 
message is not received during any of die awake periods, die terminal can simply continue to 
listen to scheduled HELLO.response packets. If a response message is expected and a 
direshold number (Lc. 1 or 2) of consecuuve HELLO.response messages are missed, dien die 
terminal should transmit a (empty) DATA.rcquest packet to its parent to determine if it is still 
in range. Note diat if die parent bridge fails to deliver a message to a child terminal then 
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either I ) the child will sec its address in a "detached node list", or 2) will reattach to the 
network after a threshold number of HELLO.responsc messages are missed, 

LLC implementaiion notes: 

An LLC layer RR (receive-ready) packet, with the final bit set ON* should be transmitted by 
the tennuial whenever the teminai attaches to the network. This ensures that higher layer 
dnui which may have been lost will be retransmitted immediately by the LLC entity at the 
remote end oi the LLC connection. 

Receive timeouts can be handled by the LLC entity in a terminal, if the bridging layer 

1 ) allows the LLC layer to pass an awake time v^dow along with a data message. 

2) provides a "requesi^messagc" service to the t-LC layer. The request_message service 
causes the bridging layer to send an "awake.time * packet to the parent bridge node. 

3) notifies the LLC layer whenever the terminal (re)attaches to the network. 

4) provides a "net^moniior'* service to the LLC layer. The net^monitor service causes the 
network layer to wake up for ail HELLO packets from die parent bridge node, and causes the 
network layer to query the parent node (with an empty DATA.request packet) wheo a HELLO 
packet is missed. 
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An example algorithm for sending a message, for which a reply message is expected, using 
type I delivery service, is shown below: 



awake.time_window->beginsmintmum.data_delay; 
awiUce_dme.window.>cnd=calculated_dataJelay; 
set_;UarmiS HORT.TIMEOUT, 

awake.dme_window->begin+awiike_time.window.>cnd+pause(0)); 
set.:i];icm(LLC^TTMEOLrr. MAX^LLCTIMEOUD: 
nei.sendCdestinauon, LLC^data. awake^dme^window);* 
net,monitor(TRUE); 

while (waidna^for^response) 
{ 

event-wait(eveni_Q); 

if (event«SHORT_TIMEOUT && request_count++ < AWAKE MAX) 
{ 

request_message<awake.cime); 
set_aIann(SHORT_TIMEOUT, paiise(request.couni)); 

} 

else if (event?=REATTACH) 

{ 

awake_time.window*>beginsO; 
awake.dme.window->end9RR.TIMEOUT; 
requesccoun^AWAKE.MAX; 
rcsei.alarm(LLC_TIMEOUT, RR^TIMEOUT); 
ae(_send(destination« LLC.RR, awake.dme.window); 

\ 

else if {evenc™LLe,TIMEOUT && retry_couni++ < LLC^MAX) 

( 

awake_dme_window->beginsO; 
awake_dme_window->cnd=RR_TIMEOUT; 
request.count=AWAKE_MAX; 
resei.alann(LLCjnMEOUT, RR.HMEOUT); 
net_send(destinatioa, LLC.RR« awake.time.window); 

} 

else 

waiQng.for.rBspoiiseBFALSE; 

} 

net.momtor(FALSE); 
set.alarm_o£f(SHORTjnMEOUD; 
sct.aJarm_off(LLC_TIMEOirr); 
return event; 

The while loop will terminate if 1) a reply message is received, 2) the maximum number of 
LLC dmeouts is exceeded, or 3) a RR/RNR frame is received from die remote LLC entity. In 
the last case, die LLC state machine will eidier determine that die original LLC data frame 
must be retransmitted or diat die LLC entity should continue to wait for a reply message. 

*Note diat die FINAL bit should be set OFF in die "LLC.data" frame so diat an unnecessary 
RR frame will not be generated by die remote LLC endcy. 
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